home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001477_daemon _Tue Jun 29 08:36:12 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA04272; Tue, 29 Jun 93 08:36:14 MET DST
  3. Return-Path: <marca@wintermute.ncsa.uiuc.edu>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA04267; Tue, 29 Jun 93 08:36:12 MET DST
  6. Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA26356; Tue, 29 Jun 1993 08:59:32 +0200
  8. Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA28177
  9.   (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 29 Jun 93 01:59:30 -0500
  10. Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
  11.     for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA24314; Tue, 29 Jun 93 02:02:20 -0500
  12. Date: Tue, 29 Jun 93 02:02:20 -0500
  13. From: marca@ncsa.uiuc.edu (Marc Andreessen)
  14. Message-Id: <9306290702.AA24314@wintermute.ncsa.uiuc.edu>
  15. To: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
  16. Cc: www-talk@nxoc01.cern.ch
  17. Subject: browser execution
  18. In-Reply-To: <21669.741272749@moose.cs.indiana.edu>
  19. References: <21669.741272749@moose.cs.indiana.edu>
  20. X-Md4-Signature: fad2e018398d81cc34a5a9def1f694e0
  21.  
  22. > >Servers are not _that_ easy to write.  They are if you're running UNIX
  23. > >and you have either inetd.conf privileges or know how to do sockets.
  24. > >Who knows what you'd have to do under VMS or MVS and you just can't
  25. > >do them under MS-DOS.  On the other hand, writing a program which
  26. > >dumps some HTML to a file is easy and possible under all systems.
  27. > >It's very similar to adding to a server, but anybody, not just the
  28. > >server administrator can do it and they can share with other non-privileged
  29. > >users.
  30.  
  31. As a side note, xinetd -- recently posted to comp.sources.unix
  32. -- allows users to run a (turbocharged version of) inetd
  33. without root privileges.
  34.  
  35. > >Even if you can easily run a server, you've got some security problems
  36. > >to deal with.  Having a browser that will execute code (or URLs, whatever)
  37. > >from documents is a little scary; having a server that anyone can
  38. > >connect to execute code is really scary.  With the browser executing
  39. > >code you leverage off the normal system authentication.  With a server,
  40. > >you have to re-invent that.  Sure, these features are coming and
  41. > >that's good; but you're building up an awful lot of stuff to solve
  42. > >a simple problem.
  43. > 
  44. > Servers can run without privilige; ours runs as id "daemon" and
  45. > doesn't have the priv to do much other than dequeue other people's
  46. > print jobs.  Surely webmasters don't run their HTTP server as root?
  47. > 
  48. > Browsers, on the other hand, have to run as users and are thus capable
  49. > of harming their users; I find using "normal system authentication"
  50. > (as it exists on most machines) to run code in this kind of situation
  51. > highly undesirable.
  52.  
  53. Having browsers execute code is *very* scary.  Servers generally run
  54. (or should run -- no reason not to) as userid 'nobody', and as such
  55. can cause practically no damage to anything.  In any case, server
  56. writers have much more knowledge about what's going to happen and what
  57. could happen while writing a server than client users do while just
  58. randomly clicking hyperlinks.  I don't see as there's any reason to
  59. think that client-side execution is safer.
  60.  
  61. > >Well, if you want to add features you have a choice.  Either make it
  62. > >harder for the browser writers or make it harder for the server writers.
  63. > >I maintain that the exec: URL scheme makes it a little harder for
  64. > >the browser writers but is a boon for server writers since it truly
  65. > >makes it easy to write a server (just like the simple inetd scripts,
  66. > >but you don't need privilege).
  67. > 
  68. > Except that what has been written isn't a server at all, it's just a
  69. > program.  It doens't provide a service to anyone except the person (or
  70. > small group of people) who have examined it, decided it safe, and
  71. > placed it on their list of commands for which exec:ing is permissible.
  72. > (unless this procedure is not used, in which case it's a security hole
  73. > you could drive an aircraft carrier through.)
  74.  
  75. What he said.
  76.  
  77. Marc
  78.